home *** CD-ROM | disk | FTP | other *** search
- Path: keats.ugrad.cs.ubc.ca!not-for-mail
- From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)
- Newsgroups: comp.lang.eiffel,comp.lang.c,comp.lang.c++,comp.object,comp.software-eng
- Subject: Re: OOA [was:Re: Beware of "C" Hackers -- A rebuttal to Bertrand Meyer]
- Date: 15 Apr 1996 09:44:42 -0700
- Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
- Message-ID: <4ktudqINN14a@keats.ugrad.cs.ubc.ca>
- References: <1995Jul3.034108.4193@rcmcon.com> <goochb.334.0015B418@rwi.com> <4kr166$1ep@news.nstn.ca> <bksDpv1r1.qI@netcom.com>
- NNTP-Posting-Host: keats.ugrad.cs.ubc.ca
-
- In article <bksDpv1r1.qI@netcom.com>,
- Bradley K. Sherman <bks@netcom.com> wrote:
- >In article <4kr166$1ep@news.nstn.ca>, dbshapco <dbshapco@fox.nstn.ca> wrote:
- >...
- >>In a nutshell, any anticipation of the solution domain pollutes analysis, to
- >>the worst case in which analysis is nothing more than an alternate way of
- >>describing implementation (ditto design). OOP should generate objects which
- >>correspond to entities in the problem domain and the relationships suggested
- >>by a well defined taxonomy, and the quality of the classes and class
- >>hierarchy vary directly with the quality of analysis. Puerile and
- >>simplisitic analysis based on inappropriate or forced correspondences usually
- >>results in crippled and incomprehensible classes and class hierarchies.
- >...
- >Excellent article. Obviously written by a practitioner.
-
- I agree. Good writing that makes for good reading.
-
- >However, well defined taxonomies are not easy to come by. The
- >problem is that the taxonomy of the woman on the warehouse floor
- >is *not* the same as the taxonomy of the guy in accounts
- >receivable which differs yet again from the salesman, ad
- >nauseum throughout the customer's organization. Each person
- >chops up the flow of work in a different way.
-
- And those puerlie and simplistic analyses and implementations do occur. It's
- natural to point the finger at the difficult OO paradigm.
-